Quote from loopingz :

Maybe you don't like the idea but if the vive was a free development sample then a $5 payment to end registration would not be a steal.

As I did say before, I don't mind paying them $5. Although I'd be happier if it was clearly stated there that the $5 would definitely allow posting. This possibility is not mentioned on this page, in the section "What features are unavailable to me?"
https://support.steampowered.com/kb_article.php?ref=3330-IAGK-7663

So in my opinion that is not clear. I did ask them about it in my very helpful and polite feedback email recently, but there was no reply from either of the three recipients. It's a little odd how they have fallen silent and ignored both emails I've sent since I explained why their rules prevented me from completing the "onboarding" process which they invited us to do. That has nothing to do with the $5, by the way. Onboarding is the thing which allows you to sell on Steam, and for some reason if not onboarded you are not allowed to talk on the SteamVR developers forum, even if they sent you a Vive.

I'll try adding $5 to my wallet if I want to say something (on the public SteamVR forum). That might seem important when I release the LFS test patch with OpenVR support.

Last edited by Scawen, Fri, 27 Nov 2015 14:14.

Quote from Shirtkicker :

So there's a possibility for specular/shine maps in the near future? This would make a lot of skin artists very happy

I discussed that very briefly with Victor. It can't work with the existing skin system, as a jpg has only r/g/b channels. I suppose what we need is one more channel? E.g. use the alpha channel to specify how shiny a pixel is. Is that the main thing that is needed? If so, what would be the best texture format for uploading skins? I won't do that for this test patch but it's something to consider.

Quote from Racer X NZ :

Have you contacted them regarding your posting rights ?

It seems pretty clear that... "Posting privileges: Only players who own SteamVR Developer Hardware are allowed to post in this forum."

Yes, I have contacted them. They told me this:

"We do require that developers complete the onboarding process to gain access to our developer forums and the available VR demos, regardless of planning to ship content via Steam or not."

But it is actually not possible for Live for Speed to complete the onboarding process. A US Taxpayer ID is required, and partnerships are specifically excluded from onboarding.

Where did you see that note about posting priviledges? I can't find it, although googling showed that someone else had seen that same text.

Quote from dawesdust_12 :

Scawen, another potential option for support/bug reporting is the Github page.

Thanks. Interestingly a couple of issues I reported by email have been fixed, although I did not get a reply to my feedback email.

Quote from nacim :

Finally! I hope you made a lot of different kind of shaders, depending on which type of object it is (grass, road, cones, tires, glass, and wall for example), that will be nice to edit or create future detailed materials later.

Did you noticed a performance improvement after converting shaders to HLSL ?

There isn't a different shader for all the materials yet. The reflections system took quite a while so I haven't gone far down the path of new shaders. There are different shaders for matt materials / shiny paint / glass / metal / black glass. But nearly all the world is simply matt materials at the moment. There are complications to consider, such as textures which are a boundary between road and grass. But of course I am interested in working on specular effects and so on for roads and grass in future.

EDIT: About performance, I did get a significant improvement, specially in the shadows code. Partly due to the shaders and partly due to a significant amount of restructuring. Now that everything uses a vertex shader and a pixel shader and the FVF system is not used, quite a lot of restructuring and optimisation could be done. I think most of the latest frame rate improvements are swallowed up by the generation of the dynamic reflections, but that depends on the situation. Also today I am adding an option to set the maximum number of dynamic environment maps. Probably separate options for the main view and the mirrors.

Last edited by Scawen, Fri, 27 Nov 2015 09:12.

Yesterday I did most of the finishing of the implementation, such as allowing the user to select Oculus Rift or Open VR, updating the translations and generally cleaning up all the related code which has changed a but to support two different VR systems.

I was busy with other things today but there was one problem remaining - judder and stutter! Just what you don't want in VR. And it was worse in menu screens. In game it was very smooth at times but bad at others. As usual, this was when doing everything the 'correct' way. So I was baffled.

This evening I decided to experiment with a few things to see if I could figure out how to get the timing right (or whatever was going wrong to cause stutter). I read a few threads about judder and stutter on the Steam VR developer forum.

The clue that allowed me to solve it came from this thread:
http://steamcommunity.com/app/358720/discussions/0/490124466474881389/

It turns out that the solution is to issue a pContext->Flush() command just after submitting the two eye textures. Now it's perfectly smooth. But I can't tell them that on the thread, because I'm not allowed to post there!

Anyway it's so smooth now I really want to get this released as soon as possible, along with the dynamic car reflections. I expect to release a test patch next week.

Quote from dawesdust_12 :

If there's any game/software/video that you find interesting that's on the Steam Marketplace, you can always purchase that and it will count as "unlocking" your account.

FWIW: I can post in the public SteamVR forum, but I cannot post in the private one. It may be worth emailing [EDIT: Gabe Newell] explaining your situation for the private one. From quickly reading, it looks like all the developers in that group have access to the Steam application for SteamVR, so they want people who are actually signed up to SteamWorks (their distribution/integration backend) for access as they have the ability to publish their demos if desired.

It makes sense that a payment can allow more access and I don't object to sending them $5. Their text should be more clear though. In fact, exactly the same vague explanation about Limited User Accounts is linked to from the SteamVR Developer Hardware forum, although it is not relevant over there. When asking for money it is best to make sure the customer knows what they will get. Vague, generic explanations aren't all that encouraging!

Anyway it sounds like the payment should get me access to the SteamVR forum so I'll probably end up doing that, if I have a question that could be answered there, or perhaps to let people know about a test patch with LFS support.

For now it's a bit of a struggle to get through the code. Their documentation has not been updated. For example it mentions functions that you need to call, but you find those functions don't exist anywhere. I found out that I need to read the change log as well, because there you can find that certain functions have been removed and there's now another method for doing what the original function did.

Also I could not find any simple step by step guide of a minimal way to get support in there. Compared with the Rift, it seems there are many different ways to implement Vive support, and hundreds of function calls available, most of which I should not need to use (hopefully). Trouble is, this makes it quite confusing!

Anyway let's see how far I can get today. Sometimes these things can get clearer as you just keep trying to do them and see what comes up...

I sent an update to Eric today and this evening I was able to test the Vive.

It's not really too hard to set up. The instructions are pretty clear and it's just a bunch of wires to plug in. I used a tripod to mount a base station in a location where it can see the floor and my seated position. In my office room there isn't really space for room scale VR so for me it is fine to use only one base station. Lucky that because the first one I tried seems to be faulty. The base stations are very "pre-production" and there is quite a bit of noise / vibration from the base station (mounted on a tripod on the left desk - maybe the desk is amplifying it). A continual hum that is much noisier than my PC, for example. I guess these will be miniaturised for the production version.

For some reason I had to stop and restart the hardware and software several times to make it work, and eventually it started to work. I can run a VR demo where you can just walk around a bit, or in my case take a step in either direction.

The screen resolution seems good in the demo. I can still see the pixels as in the Rift but my first impression is this has higher resolution than the Rift DK2. However it is not really comparable until I can see the same thing in each headset (e.g. LFS). One other thing is better in the Vive - you can turn right around and the tracking stays for much longer. Presumably this is even better when you have two base stations. I have no idea how to access any other Vive software. I'm not too bothered about that, as LFS is my main concern. I plan to have a better look at the OpenVR SDK tomorrow.

Yes, I have received the socket adapter. I am finishing off some functions for Eric and then I will test the Vive. If it works then I'll have a deeper look into Valve's OpenVR SDK. I am hoping it will all work in a similar way to the Rift without too many nasty surprises! As we have some other priorities at the moment, I don't want to get involved if it's going to take more than a few days. One good thing about OpenVR is that it is supposed to support a variety of headsets, not just the Vive.

Thank you for the test.

0.6J is now available. Just the same as 0.6H really...

Dear Hosters,

If any of you would like to test, here is the 0.6H11 DCon.

https://www.lfs.net/file_lfs.php?name=LFS_S2_DCON_6H11.zip

I don't think there are any notable changes and only the exe has changed. The only purpose of this is to make sure nothing is broken, ready for the full release which we plan to do on Saturday.

Updated first post with H11.

The change logs from H to H6 have been combined.

This is intended as the final test. Thank you all for the testing.

https://www.lfs.net/forum/thread/87997

Test Patch 0.6H6 is now available, with various fixes and some improvements. Thank you for the testing and feedback.

https://www.lfs.net/forum/thread/87997

Changes from 0.6H5 to 0.6H6

Misc :

Reduced min / max values for "Sound lag" setting - default now 0.08
Small error report added to deb.log if failed to start DirectX 9Ex
More efficient car distance sorting system for sound and graphics
More updated translations. Thank you translators.

Oculus Rift :

Updated ORDIRECT.dll to use 0.6.0.1 runtime instead of 0.6.0.0

Fixes :

CPU usage increased if minimised from full screen mode with vsync
Missing sound from nearby cars that were off screen in multiplayer
Frame rate limit system could cause lags when used in Windows 10
Frame info display could be clicked even when mouse was hidden
Virtual dashboard disappeared if another nearby car was drawn

Quote from Amynue :

https://developer.oculus.com/blog/upcoming-oculus-pc-sdk-0-7-compatibility-changes/

Thanks, they sent an information email about this. Our current official version will no longer work with the new Oculus runtime when it is released on 20th August. It seems to me the best plan for LFS is to finish the few remaining bugs and make the current version official as soon as possible, e.g. next week. Our Rift support in the test patch is based on Oculus 0.6, so it will work with the new runtime. Then I'll get on with the track shaders that can help Eric with the initial S3 tracks.

Quote from valiugera :

@Scawen, I found a mistake on Fern Bay. The wall is in the air, but Z is 0. Can you add ground level check the for new objects or add option for -Z?

I had to make that decision, to disallow Z values below zero, in order to reach the highest altitudes at Westhill. The autocross object data is highly compressed, to allow them to be passed quickly to joining racers. There is only one byte in the object data for altitude, so it can't go below zero. There are very few places in LFS which are below zero so this is the best decision. Maybe in future the sutocross object size will be increased, allowing more flexibility.

Quote from DANIEL-CRO :

BTW Scawen, is there any way we could see if Direct3D9Ex is used? I remember my RAM usage greatly decreasing when going from 0.6H -> 0.6H2 on Windows 7. Now on Windows 10 for some reason I don't get any decrease.

You can see near the start of deb.log

Aug 05 21:23:33 started Direct3D 9Ex

Quote from Neilser :

Quote from DANIEL-CRO :

My idea is to store two car positions for each car, one that is updated every 0.01s and used for physics calculation and other one that is used for purposes of moving view/camera/car.

Embarrassingly, I thought that was what LFS already did...

The real way to have graphical frames independent of physical updates is to use one thread for physics and another for graphics. The physics thread must store snapshots of the entire game state (car positions, wheel rotations, suspension extension, tyre deflections, smoke particle positions, etc) and the graphics thread can then read these and render frames in even steps between the last two physical frames. Very interesting but a truly massive task and for various reasons already described, not a good idea to do it now.

Quote from Flame CZE :

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI. It just shows the garage background during the delay.

I tested it with a clean LFS install and it occurs in H5 only, it's fine up to H4.

Anyone else with the same problem by any chance?

I didn't see that in a quick test. Can you give any more info, like if you were online or in a replay, with many cars there, etc?

I recommend Test Patch 0.6H5 - it has a significant performance improvement which is helpful at Westhill.

List of changes and download: https://www.lfs.net/forum/thread/87997

There is a good case for setting the frame rate to 100 Hz. This way, there is a read from the steering wheel for every physics calculation. Some people like higher frame rates for their own reasons. Anyway, it's interesting to see in the new moving bar chart which works well.

I had hoped to release test patch H5 this weekend but that issue with the transparent autocross objects not being visible until the optimise button is clicked has taken longer than expected. Rather than a quick fix I am working on a worthwhile improvement.

Quote from Neilser :

Holy crap. H4 is now installed. After a race a moment ago, I got this weird music in my ears for the first time ever!
Whatever you did Scawen, it made the music work on my PC and I don't ever remember hearing it before...
(I turned it off again mind you, cos it's, em, awful )

The entry screen music option is enabled when you first run this version because the audio options are stored in a more compact way and it doesn't read the old setting when it starts. Normally that music is switched off when you unlock.

Quote from nacim :

I'm back, with some benchmarks !

Sadly, I was expecting better results.

Most of the benefit of the H4 restructure is seen in stereoscopic 3D modes, where around 5% to 10% of CPU time is saved in the render, due to sharing calculations between the two eye views. I think the main benefit from H3 to H4 in non-stereo views was the bug fix - those few buildings that were drawn a slow way. That may help a little with the frame rate drop in the 3 places, but not much as it was only a few of the buildings.

But still, so much is visible at those locations that it does still slow down. I have one more thing to try. I think for the objects with a low triangle count, the CPU is still wasting too much time deciding if those objects should be drawn, and sending a request to the card for their specific vertices and triangles to be drawn. I think it is worth trying a test of just grouping these lower detail objects into a mesh that is drawn complete every frame. This would certainly help CPU usage. I will need to experiment with the number of vertices that is the threshold between these smaller objects, and the larger objects that it is worth not drawing when they are not visible.

Quote from nacim :

No, I used a single lap of 5 IAs with FBM @WE1 with replay camera on first IA.
They have done the same time, and I don't think replay is accurate for a benchmark because it doesn't compute physics.

Physics is computed in single player replays.

Test Patch 0.6H4 is now available : https://www.lfs.net/forum/thread/87997

Misc :

New Audio Option "Sound when window is inactive" (off / on)

Oculus Rift :

Reduced CPU / GPU usage by sharing scene preparation for both eyes

Fixes :

Some buildings at Westhill track were drawn using a slow method
LFS failed to resave custom textures found to be in wrong format
Using mouse wheel to change gear did not work properly at high fps

Thanks for that info. I just did a quick test adding that flag in the places where a DSBUFFERDESC is filled in. For some reason the music did keep playing but there was no car sound. But I think they use a similar system so I'm not sure why that is. I'll look into this.

Sorry that this has taken so long to fix. It must have been frustrating.

I have now looked into this and fixed it in my version. I hope to release another test patch this week with some more performance improvements.

Quote from cargame.nl :

Quote from Scawen :

In your case, is there any noticeable change from H to H2 / H2 to H3 or does it all seem much the same?

Wanted to do some screen recordings of the screen(s) here to show the differences but for some reason its not so easy reproducable at the moment... But, this machine has a bit more power. The streaming computer I cannot use anymore because of screen lag (whats the proper name for this?) .. That machine has an i7 720qm ... Its a bit weird to buy a different system just for LFS, then to see that single thread performance of much newer processors are also questionable ... Its also the wrong approach of "fixing" a problem.

I will do some random streaming to show what issues Im talking about. Will link later to video's.

I also wonder, it affects the screen, it's hard to drive.. But will it affect physics/steering input as well? I guess so. Will it affect the Rift experience? I think too, because that device is even more hardware hungry? ...

I'm confused by your text. Not really sure what you mean. It's not clear to me if you are saying there is a difference between H / H2 / H3 on your computer.

Anyway, when you say "screen lag" maybe you are talking about the effect normally called "input lag" which is when there is a noticeable delay between (e.g.) moving the controller or mouse and the on-screen steering wheel moving. This can happen when the CPU is not loaded but the GPU is drawing quite a lot. Then the GPU can get several frames behind the CPU (while trying to work through its list of things to draw and never catching up to real time) causing this strange effect. This effect can be quite extreme in some cases.

LFS has a prevention method for this (checks that the card is finished before sending more instructions to the card) so most people would never have seen that. It should be better in H3 than it was in previous versions, because it now uses an event query (DX9 function) instead of a lock (DX8 style). Though on most systems this shouldn't make a noticeable difference.

One test result I heard suggests that the input lag prevention mechanism may not have worked properly on SLI setups before H3 but should be OK now. Though LFS doesn't get any benefit from SLI anyway and may run faster with SLI disabled.

Last edited by Scawen, Fri, 3 Jul 2015 12:26.

New Test Patch 0.6H3
https://www.lfs.net/forum/thread/87997

A bit sad when people make posts like that, it's a real deflating feeling when I am hyped up and working 10-12 hour days getting loads of good things done. Not a good end to the day. Maybe I should be careful how I browse the forum in future. Just thought I'd check in and see what useful commend had been posted on the test patch thread. What I found was this spam (which was originally on the test patch thread).

Deep breath... turns off computer...

Thank you for the bug reports and suggestions (e.g. Sleep needed at some times). I confirm I can reproduce the shiny buildings bug, when a car shadow is near some of the buildings or other objects with sky reflections.

One CPU usage / frame rate optimisation I should explain to you. There is a test key (CTRL) for you to see the effect. It is an optimisation for the code when LFS is deciding, each frame, which objects to draw (by checking if their bounding sphere is on the screen). Previously it would visit each object in memory to do this crude elimination but now the centre and radius of each object is stored in a special list so that LFS doesn't have to jump around the memory to get the data. This saves on memory access and is a lot faster in some situations. The situation where it is most helpful is this :

When you are in a place where a lot of objects may be visible from that location but you are looking in a direction where not so many of them are visible.

You can test this effect by holding down CTRL at any time. You should then see a frame rate drop as it uses the old style draw. The optimisation (i.e. when you do not hold CTRL) is most useful in SHIFT+U mode, because there are no draw lists to hide most of the objects (that already avoided the radius check on most objects).

Last edited by Scawen, Sun, 21 Jun 2015 16:16.

Test Patch 0.6H2 : https://www.lfs.net/forum/thread/87997

NOTE : FULL VERSION 0.6J IS NOW AVAILABLE!
www.lfs.net/forum/thread/88217


WARNING : THIS IS A TEST

NOTE : THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR ANY NEW CONTENT

PLEASE TEST BEFORE YOU POST

PLEASE AVOID : OFF-TOPIC FEATURE REQUESTS / UNRELATED COMMENTS


Hello Racers, here is a new TEST PATCH : 0.6H11

It contains a good performance increase which is helpful at the new Westhill track.
Also there are more fixes and improvements including support for the Oculus Rift 0.6 runtime.

Entering Rift mode is now very simple : Options... View... 3D button at the top of the screen.
Do not force vertical sync in Rift mode as it would limit frame rate to monitor refresh rate.
SLI in Rift mode will probably cause a stuttering image - please disable SLI.

This test patch IS compatible with version 0.6H
This test patch CAN play replays from version 0.6H

You cannot upload hotlaps made with this test patch because it is only a test patch, not an official patch.

Please keep a backup of your LFS.exe from 0.6H so you can easily go back if there are any problems.


Changes from 0.6H10 to 0.6H11 :

Removed some debug code from the exe
Combined the test patch 0.6H2 to 0.6H6 change logs
More updated translations - thanks again translators


Changes from 0.6H6 to 0.6H10 :

Misc :

One more graphical optimisation for slightly higher frame rate
Z-buffer depth setting can now be changed without restarting LFS
Reduced some of the Z-buffer issues when using a 16 bit Z-buffer

Fixes for Windows 10 :

High CPU/GPU on ALT+TAB from full screen with vsync in Windows 10
Pause when exiting from replay or reaching end of List of Hosts


Changes from 0.6H to 0.6H6 :

Optimisations :

Static vertex buffers reorganised to reduce DirectX instructions
Frames buffered (default 1) to allow next frame to start rendering
More efficient car distance sorting system for sound and graphics
Dynamic vertex buffers now set to use hardware vertex processing
Better frame rate in places where many objects may be visible

Graphics :

Sky texture is now drawn in mirrors
Layout editor object selection buttons are sorted by distance
Mirror now uses 24 bit Z buffer if Z buffer setting is more than 16

Frame rate limitation system :

Frame rate limitation system is now accurate and has better values
New frame info display shows sleep / physics updates / gpu waiting
Now using an event query instead of a lock for input lag prevention
Minimum sleep setting changed to "Sleep every frame" (yes / no)

Misc :

Now using Direct3D 9Ex if available (Windows Vista and later)
Reduced glitch when autocross objects are optimised (e.g. on load)
Reduced min / max values for "Sound lag" setting - default now 0.08
New Audio Option "Sound when window is inactive" (off / on)

3D view modes :

Added a 3D level slider option to adjust monitor-based 3D views
Reduced CPU / GPU usage by sharing scene preparation for both eyes

Oculus Rift :

Now using Oculus SDK version 0.6.0.1 which includes timewarp
You can now enter and leave Rift mode without restarting LFS
Smooth display (if you do not use SLI or force vertical sync)
Monitor window view options : blank / one eye / two eyes

Oculus Rift compatibility mode :

For users who cannot use the Oculus 0.6 runtime, you can still use
the 0.5 runtime. Simply rename the ORDIRECT.dll to some other name
and LFS will then use LFSORDLL.dll instead (extended mode only).

Fixes :

Some buildings at Westhill track were drawn using a slow method
Mouse clipped to window (CTRL+C) now works properly with ALT+TAB
Using mouse wheel to change gear did not work properly at high fps
Layout editor object selection buttons used interface button slots
Crash changing texture resolution with two or more objects selected
Anisotropic filtering did not work on car textures (including skin)


INSTALLATION INSTRUCTIONS :

A FULL version of LFS 0.6H must already be installed

To install the PATCH using the SELF EXTRACTING ARCHIVE :

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE : You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen : 0.6H11


DOWNLOADS :


NOTE : FULL VERSION 0.6J IS NOW AVAILABLE!
www.lfs.net/forum/thread/88217


PATCH 0.6H TO 0.6H11 (SELF EXTRACTING ARCHIVE) (if you already have 0.6H) :
www.lfs.net/file_lfs.php?name=LFS_PATCH_6H_TO_6H11.exe (1.3 MB)

PATCH 0.6H TO 0.6H11 (ALTERNATIVE ZIP) (if you already have 0.6H) :
www.lfs.net/file_lfs.php?name=LFS_PATCH_6H_TO_6H11.zip (1.5 MB)

Last edited by Scawen, Sat, 15 Aug 2015 14:25.

Quote from nacim :

Thanks for finally adding sky on mirrors
Just by curiosity, when can we see the new reflections ?
I really want to see how your rendering technique is in game.

I still need to finish the car reflections and also move all the track rendering shaders to HLSL. The vertex shaders for the track objects are still written in DirectX 8 style.

But I'll release this test patch before that, hopefully today.